1. Upgrade and Migration Options
Now that we’ve identified some of the key items that
you need to consider before you move to SharePoint 2010, let’s cover the
ways in which you’ll get there. Microsoft tools support two strategies
to move from 2007 to 2010: an In-place Upgrade and a Content Database
Migration. A third option is to rebuild your environment completely from
the ground up, migrating content as needed. Table 1 highlights some of the details associated with each choice.
Table 1. Some Pros and Cons Associated with the Various Upgrade Options
| Upgrade Approach | Description | Pros | Cons | Comments |
|---|
| In-place Upgrade | Upgrades everything in one attempt | Simple; updates existing environment on current hardware | Everything is offline while it runs; no ability to revert back to an original site | Best option for single server or small farm; must meet infrastructure requirements of SharePoint 2010 |
| Content Database Migration (Database Attach) | Creates new farm and then manually migrates the old databases to the new servers | New farm, minimal downtime as the existing 2007 environment is available | Complex; many manual steps; search scopes must be recreated; additional hardware is required | Best when moving to new hardware |
| Rebuild and Selectively Migrate | Creates a new farm and then manually migrates the content from the old servers or purchases third-party migration tools | New
farm, selective data migration; allows for a fresh start with taxonomy
and security model; new functionality is available at the start and does
not need to be retrofitted | Complex;
requires many manual steps and custom code or third-party tools;
requires business and technology resources to properly design and
implement a new portal | Best
option when redesigning your portal and collaboration environment from
the ground up; especially true if the current environment is dated or
heavily customized |
In-place Upgrade
The
In-place Upgrade requires that you take the server farm offline and run
the SharePoint 2010 installer. This process updates existing databases
and servers in a single step. This is by far the simplest approach,
given that it is an automated process with minimal manual intervention.
The challenge with an In-place Upgrade is that it requires that your
existing infrastructure complies with the requirements of SharePoint
2010. As an example, that means increased RAM and 64-bit hardware on all
servers as well as specific requirements on the operating system
version (Windows Server 2008 SP2+). If you have not kept your
infrastructure to current Microsoft recommended patching levels, or you
have a large farm, or you have made customizations, an In-place Upgrade
may not be an option.
Note that just because an In-place Upgrade is not
viable for a production upgrade doesn’t mean you can’t use this approach
in a test environment to gauge the viability of the upgrade. In fact,
we highly encourage it. With the wider adoption of virtual server
technology, creating a test environment that meets the infrastructure
requirements of SharePoint 2010 and allows for an In-place Upgrade test
is very straightforward. The biggest value this approach offers is that
it allows you to see where potential upgrade hurdles exist and, as
needed, test the fixes.
Note
No matter how small or simple your SharePoint 2007
environment is, you should always test an In-place Upgrade with a copy
of your data first. This will also validate that you are working with
the appropriate and sufficient hardware.
Content Database Migration
A Content Database Migration requires that you build a
brand new server farm for the new environment. Once MOSS 2010 is
installed in the new farm, you then attach the WSS 3.0/MOSS 2007 content
database to the SharePoint Foundation 2010/SharePoint Server 2010 farm.
At that point, the content upgrade will run automatically for that
content database. The Windows SharePoint Services 3.0/MOSS 2007 farm
stays available and untouched by upgrade, which allows you to keep the
old farm up and running.
This is a good option for large and complex deployments or where you
are deploying new hardware. In fact, we suspect that this will be the
most common upgrade approach.
This is also another example of a process that can be
tested (and retested) in a virtual test environment. If your upgrade
fails during initial testing, you have the ability to troubleshoot and
resolve these issues before going live.
Note
Content Database Migration is also known as a Database Attach.
Rebuild: Create a Separate Farm and Selectively Migrate Content
Rebuilding is a good option if you want to completely
redesign your SharePoint 2010 environment from the ground up. Like the
Content Database Migration, you build a new SharePoint 2010 server farm.
But rather than letting SharePoint upgrade your content databases
automatically, you create a new set of content databases and then
selectively migrate content. This process is more manual and
time-consuming, but has the advantage of creating the “cleanest” outcome
because it gives you the opportunity to upgrade your content and
infrastructure at the same time.
2. What Plan Is Best for You?
Because every SharePoint environment is different,
every upgrade effort is different. So which upgrade option should you
choose? In some ways it depends on both the state of your current
SharePoint environment as well as your strategic vision for how you will
use the new features in the next version. Table 2
offers some real business cases and the associated recommended upgrade
strategy. The table presents a very general recommendation for simple
scenarios but offers general guidelines on where to begin planning
efforts. It is important to note that regardless of upgrade choice, the
effort associated with planning and testing is significant. The actual
technical upgrade is only one piece of the total upgrade effort.
Table 2. Some Guidance about Selecting the Appropriate Upgrade Strategy Based on Relevant Business Cases
| Business Case | Recommended Upgrade | Comments |
|---|
Relatively simple SharePoint Server 2007 environment Few customizations or third-party Web Parts Simple taxonomy that still is consistent with business needs
| In-place Upgrade (same hardware)
Database Attach (new hardware) | Because
the environment is consistent with native capabilities and because no
dramatic changes are required, an In-place Upgrade will provide the
quickest path to an operational SharePoint environment. |
Multiple organizational and team sites Team sites are being heavily used and members need the Recycle Bin and workflow Corporate content in portal areas is small and not heavily used
| Separate content into different Site Collections; then perform In-place Upgrade on each Site Collection separately | Team
site users will recognize immediate benefits from using SharePoint
Foundation 2010. There is less of an urgency of upgrading the portal.
Moving to SharePoint Foundation 2010 first will allow team members to
leverage new features while the portal content is reviewed and
eventually upgraded to SharePoint 2010. |
Very mature SharePoint Portal Server 2007 environment Site taxonomy is dated and does not reflect current business vision Lots of customization and unghosted pages
| Database Attach
or
Rebuild and Migrate | Going
to SharePoint 2010 can be a good time to evaluate your current portal
environment and do any necessary course corrections. The advantage of
starting from scratch (and migrating content) is that it allows you to
leverage new tools as they were intended (without having to retrofit
changes). |
WSS 3.0-based intranet that started as team sites and grew to become a corporate intranet Lots of pages with no easy way of navigating between pages Search is not effective and has become a major user enhancement request
| Double In-place Upgrade
or
Rebuild and Migrate | You
cannot go directly from WSS 3.0 to SharePoint Server 2010, but you can
go from WSS 3.0 to SharePoint Foundation 2010 and then upgrade again to
SharePoint Server 2010. This will maintain the current site taxonomy but
will offer better navigation and search (in addition to all the other
native SharePoint features).
You could also build a SharePoint portal from scratch and migrate
content. Again, the advantage is that you can build a new taxonomy with a
more enhanced security model. |
3. Upgrade Considerations
No
matter which process you select, there are several issues you may run
into due to the customizations made in your WSS 3.0/MOSS 2007
environment.
The following customizations could complicate your
upgrade from WSS 3.0 to SharePoint Foundation 2010 or from MOSS 2007 to
SharePoint 2010:
Styles, graphics, and branding for WSS 3.0
& MOSS 2007: You will need to re-create your branding using the new
ASP.NET master pages associated with SharePoint 2010.
Sites
based on a custom site definition: You will have to re-create the site
definition to include SharePoint Foundation 2010/SharePoint Server 2010
elements as needed and then add your definitions to the mapping file.
Custom and third-party Web Parts: You will have to redeploy these Web Parts and ensure they still work.
Web Part connections: You may have to re-create the connections.
Data
view Web Part connected to a line-of-business database: You may need to
either re-create the Web Part or consider using the Business
Connectivity Services instead.
Customized
JavaScript (for example, OWS.JS) as well as jscript. You will need to
test these to ensure they still function properly.
Document
libraries with large numbers of and/or many subfolders: You may want to
alter the list design based on SharePoint 2010’s ability to handle many
more than the 2000-item limit of SharePoint 2007.
Profile
database: You will need to reimport your profiles, which takes roughly
an hour for every 200 profiles. Make sure you budget this time.
Audiences: You will need to re-create the audiences in the new environment.
Hardcoded
URL references. If you change the underlying site topology, the URLs
associated with sites and/or documents may change, causing references to
break. Try to identify these early in your analysis.
Custom
search scopes, content sources, and best bets: You will need to recrawl
your content and re-establish any search settings you created in
SharePoint 2007.
Custom security applied to portal, sites, subsites, and document libraries: You will likely need to revisit the permissions.
For a complete upgrade guide, check out http://msdn.microsoft.com/en-us/sharepoint/ee514557.aspx.
The following are some things you absolutely must do before your upgrade:
Run the preupgrade scan tool that comes with SharePoint 2007 SP2.
Do a full backup of your databases.
Ensure you meet all infrastructure requirements associated with SharePoint 2010.
Inventory all custom Web Parts and custom coding in your SharePoint 2007 environment.
Install all prerequisites.
Create custom elements (site definitions and so on) for things you’ve customized.
For gradual upgrades, you’ll need DNS names for the new environment, which may take time to propagate across your network.
Create a communication plan to
let users know when SharePoint will be down, when things will be ready,
and what to expect.
After your upgrade, you should
Review the sites: Did SharePoint migrate the
sites correctly? Are they using the right template? Is the look and feel
acceptable?
Validate that the security model is correct.
Test search and ensure that any custom scopes or managed properties are enabled.
Look for errors in the SharePoint log or event logs. Ensure all services are running properly.
Additional Considerations
So far, we’ve outlined several questions to review in
advance of your decision to upgrade your existing SharePoint 2007
environment or migrate content to a new SharePoint 2010 environment. The
goal is to give you food for thought and, hopefully, convince you that a
move to SharePoint 2010 requires careful planning and consideration.
The decision to upgrade or migrate will be different for each
organization. It will depend on the items already discussed, your users,
and your ability to effectively deliver on the value proposition of
SharePoint 2010 technologies. So what’s your plan? Here is an outline of
some steps to help you get ready:
1. | Educate
yourself on SharePoint 2010 features. Read, see demo, find training
materials that will help you appreciate the new functionality in
SharePoint 2010 and how it maps to your business.
|
2. | Educate
yourself on how SharePoint 2010 will work in your environment. Will the
features you need really be available in the configuration you have?
|
3. | Decide
on the proper version of SharePoint 2010? Will you use SharePoint
Foundation 2010 only? Or SharePoint Server 2010 Standard? Or, do you
need extended business intelligence capabilities, Excel Services,
business connectivity services, or a forms server offered by SharePoint
Server 2010 Enterprise?
|
4. | Identify
the new features that you would like to implement (workflow, offline,
and so on) and think about how they will integrate with the existing
information architecture.
|
5. | Document
all the customizations made in your current environment. These include
templates, Web Parts, and styles. This will serve as your checklist for
functional validation as you go into Step 6.
|
6. | Create
a test environment with a copy of your existing SharePoint portal. Test
the upgrade. Whether or not you have already made your decision, it is
best to validate the upgrade process and identify any potential problem
areas. Perform either an In-place Upgrade (or a partial upgrade if you
have a lot of Site Collections) and get your portal up and running.
|
7. | Next,
verify that you can get all items that you documented in Step 5 to work
successfully. Does the portal meet your needs? Will the downtime of an
In-place Upgrade be acceptable to users?
|
8. | Conduct
focus group testing with representative users. Show them the upgraded
portal. Demonstrate some of the new features. Talk to them about the
positives and negatives of the existing environments. Identify your
“killer applications.”
|
9. | Do
a whiteboard session with portal team representatives. Lay out your
current taxonomy. Talk about some of the feedback from the focus groups.
Identify how the features identified in Step 4 will be integrated.
Devise a proposed new portal taxonomy.
|
10. | Take
a step back. Reflect. After going through the process, how do you feel?
Will an In-place Upgrade suffice? Or do you need to do a gradual
upgrade? Or is this an opportunity to build something new (and better)
and introduce significant business value? How will you get there? How
long will it take? Do you need help?
|
11. | Be sure to visit the Microsoft TechNet site for detailed upgrade information at http://msdn.microsoft.com/en-us/sharepoint/ee514557.aspx. |
